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Abstract 

We conduct a security analysis of five popular web-based 
password managers. Unlike "local" password managers, 
web-based password managers run in the browser. We 
identify four key security concerns for web-based pass- 
word managers and, for each, identify representative vul- 
nerabilities through our case studies. Our attacks are se- 
vere: in four out of the five password managers we stud- 
ied, an attacker can learn a user's credentials for arbi- 
trary websites. We find vulnerabilities in diverse features 
like one-time passwords, bookmarklets, and shared pass- 
words. The root-causes of the vulnerabilities are also di- 
verse: ranging from logic and authorization mistakes to 
misunderstandings about the web security model, in ad- 
dition to the typical vulnerabilities like CSRF and XSS. 
Our study suggests that it remains to be a challenge for 
the password managers to be secure. To guide future de- 
velopment of password managers, we provide guidance 
for password managers. Given the diversity of vulner- 
abilities we identified, we advocate a defense-in-depth 
approach to ensure security of password managers. 

1 Introduction 

It is a truth universally acknowledged, that password- 
based authentication on the web is insecure. One pri- 
mary, if not the primary, concern with password authen- 
tication is the cognitive burden of choosing secure, ran- 
dom passwords across all the sites that rely on pass- 
word authentication. A large body of evidence suggests 
users have — possibly, rationally [20] — given up, choos- 
ing simple passwords and reusing them across sites. 

Password managers aim to provide a way out of this 
dire scenario. A secure password manager could au- 
tomatically generate and fill-in passwords on websites, 
freeing users from the cognitive burden of remembering 
them. Additionally, since password managers automati- 
cally fill in passwords based on the current location of the 
page, they also provide some protection against phish- 
ing attacks. Add cloud-based synchronization across de- 



vices, and password managers promise tremendous se- 
curity and usability benefits at minimal deployability 
costs [10]. 

Given these advantages, the popular media often ex- 
tols the security advantages of modern password man- 
agers (e.g., CNET [11], PC Magazine [29], and New 
York Times [32]). Even technical publications, from 
books [12, 34] to papers [19], recommend password 
managers. A recent US-CERT publication [21] notes: 

[A Password Manager] is one of the best 
ways to keep track of each unique password 
or passphrase that you have created for your 
various online accounts without writing them 
down on a piece of paper and risking that oth- 
ers will see them. 

Unsurprisingly, users are increasingly looking towards 
password managers for relieving password fatigue. Last- 
Pass, a web-based password manager that syncs across 
devices, claimed to have over a million users in Jan- 
uary 2011 [25]. PasswordBox, launched in May 2013, 
claims to have over a million users in less than three 
months [42]. 

Our work aims to evaluate the security of popular 
password managers in practice. While idealized pass- 
word managers provide a lot of advantages, implemen- 
tation flaws can negate all the advantages of an idealized 
password manager, similar to previous results with other 
password replacement schemes such as SSOs [40, 38]. 
We aim to understand the current state of password man- 
agers and identify best practices and anti-patterns to 
guide the design of current and future password man- 
agers. 

Widespread adoption of insecure password managers 
could make things worse: adding a new, untested sin- 
gle point of failure to the web authentication ecosystem. 
After all, a vulnerability in a password manager could 
allow an attacker to steal all passwords for a user in a 
single swoop. Given the increasing popularity of pass- 
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word managers, the possibility of vulnerable password 
managers is disconcerting and motivates our work. 

We conduct a comprehensive security analysis of five 
popular, modern web-based password managers. We 
identified four key concerns for modern web-based pass- 
word managers: bookmarklet vulnerabilities, "classic" 
web vulnerabilities, logic vulnerabilities, and UI vulner- 
abilities. Using this framework for our analysis, we stud- 
ied each password application and found multiple vulner- 
abilities of each of the four types. 

Our attacks are severe: in four out of the five password 
managers we studied, an attacker can learn a user's cre- 
dentials for arbitrary websites. We find vulnerabilities in 
diverse features like one-time passwords, bookmarklets, 
and shared passwords. The root-causes of the vulnerabil- 
ities are also diverse: ranging from logic and authoriza- 
tion mistakes to misunderstandings about the web secu- 
rity model, in addition to vulnerabilities like CSRF and 
XSS. 

All the password manager applications we studied are 
proprietary and rely on code obfuscation/minification 
techniques. In the absence of standard, cross-platform 
mechanisms, the password managers we study imple- 
ment features like auto-fill, client-side encryption, and 
one-time password in diverse ways. The password man- 
agers we study also lack a published security architec- 
ture. All these issues combine to make analysis difficult. 

Our main contribution is systematically identifying the 
attack surface, security goals, and vulnerabilities in pop- 
ular password managers. Modern web-based password 
managers are complex applications and our systematic 
approach enables a comprehensive security analysis (in 
contrast to typical manual approaches). 

Millions of users trust these vulnerable password man- 
agers to securely store their secrets. Our study strikes a 
note of caution: while in theory password managers pro- 
vide a number of advantages, it appears that real-world 
password managers are often insecure. 

Finally, to guide future development of password man- 
agers, we provide guidance for password managers. We 
identify anti-patterns that could hide more vulnerabili- 
ties; architectural and protocol changes that would fix the 
vulnerabilities; as well as identify mitigations (such as 
Content Security Policy [14]) that could have mitigated 
some vulnerabilities. Our focus is not on finding fixes for 
the vulnerabilities we identified; instead, our guidance 
is broader and aims to reduce and mitigate any future 
vulnerabilities. Given the diversity of vulnerabilities we 
identified, we believe a defense-in-depth approach has 
the best shot at ensuring the security of password man- 
agers. 

Ethics and Responsible Disclosure. We experimen- 
tally verified all our attacks in an ethical manner. We 
reported all the attacks discussed below to the software 



Alice a legitimate user 

Bob a legitimate collaborator 

hunter2 an example password 

dropbox . com a benign web application 

f acebook . com a benign web application 

/login entry point (login page) for a web application 

Mallory an attacker 

Eve an attacker 

evil . com a website controlled by an attacker 

dropbox . com The dropbox.com JavaScript code 

running in the browser 

Figure 1: Naming convention used in the paper. URLs 
default to https unless otherwise specified. 



vendors affected in the last week of August 2013. Four 
out of the five vendors responded within a week of our 
report, while one (NeedMyPassword) still has not re- 
sponded to our report. Aside from linkability vulnera- 
bilities and those found in NeedMyPassword, all other 
bugs that we describe in the paper have been fixed by 
vendors within days after disclosure. None of the pass- 
word managers had a bug bounty program. 

Organization. We organize the rest of the paper as 
follows: Section 2 provides background on modern web- 
based password managers and their features. We also ar- 
ticulate their security goals and explain our threat model 
in Section 2. Next, we present the four key sources of 
vulnerabilities we used to guide our analysis (Section 3). 
Section 4 presents our study of five representative pass- 
word managers, broken down by the source of vulnera- 
bilities (per Section 3). We provide guidance to password 
managers in Section 5. We present related work in Sec- 
tion 6 before concluding (Section 7). 

2 Background 

To start, we explain the concept of a password manager 
and discuss some salient features in modern implemen- 
tations. We also briefly list the password managers we 
studied, identify the threat model we work with, and the 
security goals for web-based password managers. Here 
and throughout this paper, we rely on a familiar naming 
convention (presented in Figure 1) to identify users, web 
applications, and attackers. 

2.1 A Basic Password Manager 

At its core, a password manager exists as a database to 
store a user's passwords and usernames on different sites. 
The password manager controls access to this database 
via a master username/password. A secure password 
manager, with a strong master password, ensures that a 
user can rely on distinct, unguessable passwords for each 
web application without the associated cognitive burden 
of memorizing all them. Instead, the user only has to 
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remember one strong master password. 

A password manager maintains a database of a user's 
credentials on different web applications. A web appli- 
cation is a site that authenticates its users by asking for a 
username/password combination. The web application's 
"entry point" is the page where the application's user can 
enter her username and password. We call the combina- 
tion of an entry point, username, and password a creden- 
tial. A user can store multiple credentials for the same 
web application, in which case a name distinguishes each 
(typically the username). 

Figure 2 (a) illustrates the general protocol of how a 
user (Alice) uses a password manager (e.g., LastPass) to 
log in to a web application (e.g., Dropbox). Alice first 
logs in to the password manager using her master user- 
name/password (her LastPass username and password), 
as shown in Step (T). Then, in Step (2), Alice retrieves 
her credential for dropbox . com. Finally, Alice uses this 
credential to log into dropbox . com in Step (3) and (4). 

Since manually retrieving and sending credentials is 
cumbersome, password managers may also automate the 
process of selecting the appropriate credential and log- 
ging in to the opened web application. This may include 
navigating a web browser to the entry point, filling in 
some text boxes with the username/password, and sub- 
mitting the login form. Since these tasks involve execut- 
ing code inside the web application, password managers 
often rely on a privileged browser extension or a book- 
marklet for the same. 

2.2 Features in Modern Password Man- 
agers 

Modern password managers provide a number of conve- 
nience and security features that are relevant to a security 
analysis. We briefly elucidate three below. 




(a), authentication to a web application (b). sharing with a collaborator 

Figure 2: Different parties in a password manager 
scheme 

Collaboration. Modern password managers include 
the ability to share passwords with a collaborator. Fig- 
ure 2 (b) illustrates the general protocol of how a user Al- 
ice shares a credential of hers with a collaborator Bob. In 
Step CD, Alice requests that the password manager share 
a specified credential with Bob. In Step (2), the pass- 
word manager forwards the credential to Bob when Bob 
requests it. Both Alice and Bob need accounts with the 



password manager. Myllogin even allows the password 
owner to set read/write permissions on the shared creden- 
tials, but the efficacy of these fine-grained controls is not 
clear, since denying write access does not prevent a col- 
laborator from going to the web application and changing 
the account's password. 

Credential Encryption. Due to the particularly sen- 
sitive nature of the data handled by password managers, 
password managers aim to minimize the amount of 
code and personnel with access to the credentials in the 
clear. One common technique is encrypting the creden- 
tial database on the user's computer, thus preventing a 
passive attacker at the server-side from accessing the cre- 
dentials in plaintext. In web-based password managers, 
this corresponds to using JavaScript to encrypt pass- 
words on the client side (including pages on the pass- 
word manager's website, browser extensions, and book- 
marklets). The password manager encrypts/decrypts the 
credential database using a key derivation function start- 
ing from a user provided secret. If the password man- 
ager supports credential encryption, we call the encryp- 
tion key the user's master key. For example, LastPass 
uses JavaScript to decrypt/encrypt the user's credential 
database using a key derived from the user's master user- 
name and password. 

Login Bookmarklets. As discussed above, password 
managers typically rely on browser extensions to im- 
plement auto-fill and auto-login functionality. Unfortu- 
nately, users can only install these in a browser that sup- 
ports extensions. With the popularity of mobile devices 
whose browsers lack support for extension APIs (e.g., 
Mobile Safari or Internet Explorer), password managers 
have adopted a more portable solution by providing a 
bookmarklet. A bookmarklet is a snippet of JavaScript 
code that installs as a bookmark, which, instead of navi- 
gating to a URL when activated, runs the JavaScript snip- 
pet in the (possibly malicious) context of the current page 
(e.g., evil . com). This allows the password manager to 
interact with a login form using widely supported book- 
marking mechanisms. 

2.3 Representative Password Manager Ap- 
plications 

To evaluate the security of modern password managers, 
we studied a representative sample of five modern pass- 
word managers supporting a diverse mix of features. 
Table 1 provides an overview of their features. The 
columns "Extension" and "Bookmarklet" indicate sup- 
port for login automation through the particular mecha- 
nism; "Website" indicates the presence of a web-based 
account management interface; and "Credential Encryp- 
tion" and "Collaboration" refer to the features described 
in Section 2.2. For password managers supporting cre- 
dential encryption, Table 1 also lists their key derivation 
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KDF (p , s , c , 1) is a key derivation function [23], which derives key of length / octets for the password p, the salt s, and the iteration count c. 



Table 1: List of Password Managers Studied. 



function and the fields encrypted. 

2.3.1 LastPass 

LastPass [24] is a popular, award-winning password 
manager available on phones, tablets, and desktops for 
all the major operating systems and browsers. It is 
the top-rated and Editors' Choice password manager for 
both PC Magazine [29] and CNET [11]. As of August 
2013, LastPass had over one million users. 

LastPass is one of the most full-featured password 
manager applications available. It supports nearly all ma- 
jor browsers and mobile/desktop platforms and includes 
features such as bookmarklets, one-time passwords, and 
two-factor authentication. LastPass users can access 
their credentials using the LastPass extension, through 
a bookmarklet, or directly through the LastPass website. 
LastPass stores the credential database encrypted on the 
LastPass servers and also allows users to share passwords 
with each other. 

2.3.2 RoboForm 

RoboForm (Everywhere) [33] is another top-rated pass- 
word manager [29]. 1 In RoboForm, each credential 
(i.e., username, password, and entry point tuple) has 
its own file named (by default) after the web applica- 
tion's domain. For example, RoboForm uses "drop- 
box" as the default filename when saving credentials for 
dropbox . com. The user can also choose arbitrary names 
for the files. Unless the user creates a master password to 
protect the files, these credential files are sent to Robo- 
Form servers in the clear. The user can access her cre- 
dential files directly through the RoboForm website or 
via the RoboForm extension or bookmarklet. 



'RoboForm (Desktop) is a version of RoboForm that only stores 
credentials on a single computer and does not sync across devices us- 
ing a web server. We focus only on the web-based RoboForm (Every- 
where) software. 



2.3.3 Myllogin 

Myllogin is a web-based password manager, launched 
in April 2012; it started a special business-targeted prod- 
uct launched in May 2013. Our study was based on a 
then-beta version of their consumer-facing service. For 
maximum compatibility, Myllogin relies exclusively on 
bookmarklets and does not provide any browser exten- 
sions. Users can access credentials via a web appli- 
cation. Myllogin also supports sharing of credentials 
between two Myllogin accounts. Myllogin stores all 
credentials encrypted at the server-side with a special 
passphrase that the user sets up. In contrast to other 
password managers, which use the standard PBKDF al- 
gorithm, Myllogin concatenates the MD5 hash of odd 
and even characters of the passphrase to generate a 256- 
bit key. We do not comment on this further because we 
found a simpler, more severe flaw in Myllogin [27]. 

2.3.4 PasswordBox 

PasswordBox [31], a web-based password manager that 
launched in 2013, is highly rated by both PC Maga- 
zine [29] and CNET [11]. Within three months of its 
inception in May 2013, PasswordBox had attracted over 
one million users [42]. PasswordBox, unlike other pass- 
word managers discussed earlier, does not support book- 
marklets; instead, it requires users to install a browser 
extension. PasswordBox also allows sharing credentials 
between users and encrypts all passwords using a 256-bit 
key derived using 10000 iterations of PBKDF2 and the 
PasswordBox username as the salt. 

2.3.5 NeedMyPassword 

Finally, we also studied a basic password manager 
named NeedMyPassword [30]. NeedMyPassword lacks 
common features such as auto-login, credential sharing, 
and password generation. Instead, it provides only cre- 
dential storage, accessible through the NeedMyPassword 
website. User credentials are not encrypted before send- 
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ing to NeedMyPassword servers. 

2.4 Threat Model 

Our main threat model is the web attacker [2]. Briefly, a 
web attacker controls one or more web servers and DNS 
domains and can get a victim to visit domains controlled 
by the attacker. We believe this is the key threat model 
for web-based password managers that often run in the 
browser. For our study, we extend this model a bit: the 
user may create an account on the attacker's web appli- 
cation and use the password manager for managing the 
credentials for the same. Our threat model allows the 
victim to rely on the password manager's extension, the 
bookmarklet, and website as she sees fit. The attacker 
can also create accounts in the password manager service 
and make requests to the password manager directly. 

The password manager's code often runs in a web ap- 
plication's origin (via an extension or a bookmarklet). 
We assume that the password manager's code is not ma- 
licious and does not steal sensitive data from web ap- 
plications. We also assume that the password manager 
does not share Alice's credentials with user Bob, unless 
asked to do so by Alice. Additionally, we assume that 
the user uses a unique password for the password man- 
ager and does not share it with other applications such as 
evil . com. 

2.5 Security Goal 

At a high level, a password manager only has one key 
security invariant: ensure that a stored password is ac- 
cessed only by the authorized user(s) and the website the 
password is for. We discuss how password managers (at- 
tempt to) achieve this invariant by following four security 
goals. A related taxonomy appears in Bonneau et al.'s 
analysis of general web authentication schemes [10], but 
ours is a bit different since we focus exclusively on web- 
based password managers. Nonetheless, all our goals 
map to goals mentioned in Bonneau et al.'s work. As 
we present in Section 4, we found attacks that violate 
all of the security goals identified below and range from 
complete (password manager) account takeover to pri- 
vacy violations. 

Master Account Security. The first goal of password 
manager application is the integrity of the master ac- 
count. It should be impossible for an attacker to authen- 
ticate as the user to the password manager. It is crucial 
that the password manager maintain the security of the 
master account and safeguard credentials such as mas- 
ter password and cookies. In case of password managers 
that encrypt credentials, the master key/password used to 
encrypt the credential database should always remain at 
the client-side. 

Credential Database Security. The main responsi- 
bility of a password manager is securely storing the list 



of a user's credentials. A password manager needs to 
ensure the security — including confidentiality, integrity, 
and availability — of the credential database. The at- 
tacker, Eve, should not be able to learn Alice's creden- 
tials, which would allow Eve to log in as Alice; or modify 
credentials, which would allow Eve to carry out a form of 
login CSRF attacks; or delete credentials, which would 
allow Eve to carry out a denial-of-service attack on Al- 
ice. 

Collaborator Integrity. The collaboration, or shar- 
ing, feature in modern password managers complicates 
credential databases. Now, each credential has an access- 
control list identifying the list of users allowed to read- 
/write the credential. A password manager must ensure 
the security of this feature: e.g., flaws in this feature 
could allow an attacker to learn a user's credential. While 
we realize that these goals are a subset of the broader 
goal of credential database security (above), we sepa- 
rated them out to highlight the security concerns of the 
sharing credentials feature. 

Unlinkability. The use of a password manager should 
not allow colluding web applications to track a single 
user across websites, possibly due to leaked identifiers. 
We use the Bonneau et al.'s definition of unlinkabil- 
ity [10]: a password manager violates unlinkability if 
it allows tracking a user across web applications even 
in the absence of other techniques like web fingerprint- 
ing [16]. For example, a privacy-minded user could rely 
on different browsers or computers to foil web browser 
fingerprinting; a password manager should not add a re- 
liable fingerprinting mechanism that makes that effort 
moot. Such a fingerprinting mechanism would violate 
the user's privacy expectations. Equivalently, relying on 
a password manager should not allow a web application 
to link two accounts owned by the user with the (same) 
web application. 

3 Attack Surface 

The key difference between web-based password man- 
agers and "local" password managers is their need to 
work in web browsers. Web-based password managers 
store credentials in the cloud and a user logs on to the 
manager to retrieve his/her credentials. Access to the 
stored credentials is via extensions, a website, or even 
bookmarklets — all of which run in the browser. 

To guide our investigation, we identified four key con- 
cerns for modern web-based password managers: book- 
marklet vulnerabilities, classic web vulnerabilities, au- 
thorization vulnerabilities, and UI vulnerabilities. We 
discuss each in turn below. In the next section, we will 
present representative vulnerabilities of each type. 
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3.1 Bookmarklet Vulnerabilities 

JavaScript is a dynamic, extensible language with deep 
support for meta-programming. The bookmarklet code, 
running in the context of the attacker's JavaScript con- 
text cannot trust any of the APIs available to typical web 
applications — an attacker could have replaced them with 
malicious code. Relying too much on these APIs has cre- 
ated a class of vulnerabilities unique to web-based pass- 
word managers. 

To fill in a password on (say) dropbox . com, a pass- 
word manager needs to successfully authenticate a user, 
download the (possibly encrypted) credential, decrypt it 
(if necessary), authenticate the web application, and, fi- 
nally, perform the login. Doing all this in an untrusted 
website's scripting environment (as a bookmarklet does) 
is tricky. In fact, three of the five password managers we 
studied (Table 1) provide full-fledged bookmarklet sup- 
port, and all of them were vulnerable to attacks ranging 
from credential theft to linkability attacks (Section 4). 

Browser extensions, which modified the webpage, 
faced a similar problem in the past. Currently, both Fire- 
fox and Chrome instead provide native or isolated APIs 
for browser extensions. Unfortunately, popular mobile 
browsers, including Safari on iOS, Chrome on Android/i- 
Phone, and the stock Android Browser, do not support 
extensions. As a result, web-based password managers 
often rely on bookmarklets instead. 

3.2 Web Vulnerabilities 

A password manager runs in a web browser, where 
it must coexist with the web applications whose pass- 
words it manages as well as other untrusted sites. Un- 
fortunately, relying on the web platform for a security- 
sensitive application such as password managers is 
fraught with challenges. 

Web-based password manager developers need to un- 
derstand the security model of the web. For exam- 
ple, browsers share authentication tokens such as cook- 
ies across applications (including across applications and 
extensions), leading to attacks such as cross-site request 
forgery (CSRF). Applications running in the browser 
runtime also need to sanitize all untrusted input before 
inserting it into the document; insufficient sanitization 
could lead to cross-site scripting attacks, which in the 
web security model implies a complete compromise. 

3.3 Authorization Vulnerabilities 

Sharing credentials increases the complexity of securing 
password managers. While previously, each credential 
was only accessible by its owner, now each credential 
needs an access control list. Any user could potentially 
access a credential belonging to Alice, if Alice has autho- 
rized it. A password manager needs to ensure that all ac- 
tions related to sharing/updating credentials are fully au- 



thorized. Confusing authentication for authorization is a 
classic security vulnerability, one that we find even pass- 
word managers make (Section 4). We separate out au- 
thorization vulnerabilities from web vulnerabilities since 
they are often due to a missing check at the server-side. 
For example, all our authorization vulnerabilities involve 
requests made by an attacker from his own browser, not 
via Alice's browser (when Alice visits evil . com). 

3.4 User Interface Vulnerabilities 

A major benefit of password managers is their ability to 
mitigate phishing attacks. Users do not actually mem- 
orize the password for a web application; instead, they 
rely on the password manager to detect which applica- 
tion is open and fill in the right password. The logic that 
performs this is impervious to phishing attacks: it will 
only look at the URL to determine which credential to 
use. 

These advantages are moot if the password manager 
itself is vulnerable to phishing attacks. Even worse, in 
the case of password managers, a single phishing attack 
can expose all of a user's credentials. Thus, we believe 
it behooves password managers to take extra precau- 
tions against phishing attacks. While it is possible that 
password managers are susceptible to classic phishing 
attacks, we focus on anti-patterns that make password 
managers more vulnerable than the typical website. 

For example, consider what happens when a user 
clicks on a password manager's bookmarklet while not 
logged in to the password manager. A simple option 
is asking the user to login in an iframe. Unfortunately, 
this is trivial for the attacker to intercept and replace the 
iframe with a fake dialog. Since users cannot see the 
URL of an iframe, there is no way for a user to identify 
whether a particular iframe actually belongs to the pass- 
word manager and is not spoofed. We argue that this is 
an anti-pattern that password managers should avoid. 

4 Security Analysis of Web-based Pass- 
word Managers 

Next, we report the results of our security analysis of five 
popular password managers. We organize our results per 
the discussion in Section 3. Table 2 summarizes the vul- 
nerabilities we found. Our discussion below highlights 
the presence of different types of security vulnerabili- 
ties in web-based password managers. We do not present 
complete architectural details of each password manager; 
instead, we only provide enough technical details to un- 
derstand each vulnerability. 

4.1 Bookmarklet Vulnerabilities 

As discussed earlier, a bookmarklet allows a user of a 
password manager to log in to web applications with- 
out needing to install any extension, a particularly useful 
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Table 2: Summary of Vulnerabilities Discovered. NA identifies vulnerabilities not applicable to the particular password 
manager because it does not provide the relevant functionality. 



feature with mobile browsers that lack extension support. 
Three of the password managers we studied — LastPass, 
RoboForm, and Myllogin — provide access to creden- 
tials and auto-fill functionality using bookmarklets. In 
fact, Myllogin only provides bookmarklet for auto-fill 
support, advertising it as a feature ("No install needed"). 

We found critical vulnerabilities in all three book- 
marklets we studied. If a user clicks on the bookmarklet 
on an attacker's site, the attacker, in all three cases, learns 
credentials for arbitrary websites. We only discuss one 
representative vulnerability here and provide details of 
the other two vulnerabilities in our extended technical 
report [27]. 

While in 2009 Adida et al. identified attacks on pass- 
word manager bookmarklets [1], our study indicates that 
these issues still plague password managers. This is par- 
ticularly a cause of concern given the popularity of mo- 
bile devices that lack full-fledged support for extensions. 

4.1.1 Case Study: LastPass Bookmarklet 

LastPass stores the credential database on the 
lastpass.com servers encrypted with a master_key, 
which is a 256-bit symmetric key derived from the user's 
master username and master password. The LastPass 
client-side code never sends the master password or 
master key to the LastPass servers. 

Recall that a bookmarklet runs in the context of the 
(possibly malicious) web application. At the same time, 
due to LastPass's credential encryption, the bookmarklet 
needs to include the secret master_key (or a way to 
get to it), to decrypt the credential database. Including 
this secret in the bookmarklet, while still keeping it se- 
cret from the web application, is tricky. LastPass also 
provides the ability to revoke a previously created book- 
marklet, further complicating this feature. 

Installing a Bookmarklet. A user, Alice, wish- 
ing to install a bookmarklet needs to create a special 
link through her LastPass settings page. On Alice's re- 
quest, the LastPass page code creates a new random 
value _LASTPASS_RAND and encrypts the master_key 
with it, all within Alice's browser. The LastPass 
servers then store this encrypted master key (called 
key_rand_encrypted) and an identifier h along with 
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2. extract d and 
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^ extract the credential for u from a, mice, 
D _LASTPASS_RAND, and key_rand_encrypted 
jL : credential 



Figure 3: LastPass: Automatic login using bookmarklet. 
u is the domain on which Alice clicked on the book- 
marklet. 



Alice's credential database. The page then creates a 
JavaScript snippet containing _LASTPASS_RAND and h, 
which Alice can save as a bookmark. This design al- 
lows Alice to revoke this bookmarklet in the future by 
just deleting the corresponding h and encrypted master 
key from the LastPass servers. 

Using the Bookmarklet. Figure 3 illustrates how 
Alice uses her LastPass bookmarklet to log in to 
dropbox. com. At the Dropbox entry point, Alice clicks 
on her LastPass bookmarklet, which includes the token 
_LASTPASS_RAND and h. The bookmarklet code first 
checks the current page's domain and adds a script el- 
ement to the page sourced from lastpass . com. The 
request for the script element (Step 2 in Figure 3) sends 
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._LASTPASS_RAND\h " 



evil.com 



ref\rh\h\u 



BjBEZBl 



li = dropbox.com 
ref = u 

alice | d | keyrandencrypted 



1. check cookies and h 

2. extract d and 
keyrandencrypted 



extract the credential for i( from d, alice, 
LASTPASS_RAND, and key_rand_encrypted 



Figure 4: Attack on LastPass bookmarklet based auto- 
login. The rh,h values are random; u and ref identify 
the Malloy's target website. 



h and the web application domain dropbox . com as pa- 
rameters h and u. LastPass checks h and if the parameter 
is valid (i.e., Alice has not revoked the bookmarklet), re- 
sponds with a JavaScript file containing the additional 
parameters ref and rh. 

Next, the newly fetched JavaScript file creates 
an iframe to lastpass.com using four parame- 
ters: ref ,rh,h,u. This iframe includes a script 
located at lastpass . com/bml . php?u=dropbox. com 
that, when downloaded, includes the encrypted mas- 
ter key key_rand_encrypted and the credential for 
dropbox . com encrypted with the master key. The iframe 
then receives the bookmarklet's _LASTPASS_RAND value 
via a postMessage call, decrypts the dropbox . com cre- 
dential and sends them back. 

Vulnerability. The resource at 

bml . php?u=dropbox . com (Step 6 Figure 3) is at a pre- 
dictable URI and contains sensitive information. It pro- 
vides the encrypted master key key_rand_encrypted 
and the credential for dropbox . com. The same-origin 
policy allows an attacker to include a script from any 
origin and execute it in the attacker's webpage. 

LastPass Bookmarklet Attack. Figure 4 illustrates 
how a malicious web application evil . com can steal 
Alice's credential for dropbox . com. When Alice vis- 
its the attacker's site evil . com and clicks her LastPass 
bookmarklet, the attacker uses any of a number of hijack 
techniques [1, 8] (e.g., Function. toSource) and ex- 
tracts both h and _LASTPASS_RAND. Then, the attacker 
imitates Step 6 from Figure 3 (as Step 2 here) by writ- 
ing a <script> tag with src set to lastpass.com/ 
bml.php?u=dropbox.com and adding the parameters 
rh (any string of length 64), r (any number), and h (from 
the bookmarklet). 

The downloaded script, which runs on the at- 
tacker's page, includes all the information needed 
to decrypt credential for dropbox . com (notably, 
key_rand_encrypted). Again, the attacker uses the 
JavaScript hijack technique to extract out the encrypted 
credential and decrypts them with the _LASTPASS_RAND 



value stolen earlier. The attacker can repeat the attack to 
steal all of Alice's credentials, violating the confidential- 
ity of the credential database. 

LastPass Linkability Attack. Finally, we note that 
the h and _LASTPASS_RAND remain the same across 
browsers but differ by user. As discussed above, any 
website where the user clicks the bookmarklet can learn 
these pseudo-identifiers h and _LASTPASS_RAND [1]. 
This allows colluding websites to track a user, violating 
the user's privacy expectations [10]. Additionally, this 
also allows a single website to identify and link multiple 
accounts belonging to the same user, which violates the 
unlinkability goal. 

4.2 Web Vulnerabilities 

Next, we study vulnerabilities in password managers 
caused due to subtleties of the web platform. We focus 
on CSRF and XSS vulnerabilities, which are common in 
web applications. We find CSRF vulnerabilities in Last- 
Pass, RoboForm, and NeedMyPassword as well as XSS 
vulnerabilities in NeedMyPassword. 

Our attacks are severe: XSS vulnerabilities in Need- 
MyPassword allow for complete account takeover, while 
the CSRF vulnerabilities in RoboForm allow an attacker 
to update, delete, and add arbitrary credentials to a user's 
credential database. We only discuss the CSRF vul- 
nerability in LastPass here and discuss the remaining 
CSRF and XSS vulnerabilities in our extended technical 
report[27]. 

4.2.1 Case Study: LastPass One Time Password 

One-Time password (OTP) is a feature of LastPass that 
allows a user to generate an authentication code for the 
master account that is only valid for one use. A user can 
use a one-time password to prevent a physical observer 
from gaining access to her LastPass account [10]. 

Generating an OTP. Before getting into the details, 
we point out that Alice's LastPass OTP must be able to 
authenticate Alice to LastPass and allow Alice to recover 
her master key; all without revealing anything extra (in- 
cluding the OTP itself) to LastPass servers (since that 
would defeat the credential encryption feature). 

Figure 5 illustrates how Alice creates an OTP 
otp. This starts with Alice creating a string otp 
locally in her browser. Next, Alice computes 
h = hash (hash (alice I otp) I otp) with her LastPass 
username alice. LastPass will use h to authenti- 
cate Alice, without having to know the exact value 
of otp. Then, Alice encrypts her master key with 
hash(alice I otp) . Alice sends h and the encrypted 
master key (rand_encrypted_key) to LastPass. No- 
tice that the LastPass servers never see the generated 
one-time password or Alice's master key in the clear. 
LastPass saves a record associating the values h and 
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laslpass.com/otp.php 

locally generate an OTP otp 



h\rand_encrypted_key 
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ok 



/validate user by checking cookies 

save (email, h,rand_encrypted_key) 
to the backend storage 

© 



Figure 5: LastPass OTP Creation. Note the absence of 
any CSRF token in the request in Step 1 . 



lastpass.com/otp.php ?forcelogin=l 
type email and OTP otp 



compute h - hash(hash(email\otp)\otp) 



randencryptedkey 



I check if (email,h,randencryptedkey) 
exists in the backend storage 
for some rand encrypted key 



\ extract localkey by decrypting rand encrypted key 
' using hash(email\otp) 



Figure 6: Using the LastPass 

OTP.rand_encrypted_key is the master key encrypted 
with hash(alice I otp), 



rand_encrypted_key with Alice's LastPass username. 

Using the OTP. To sign in with her OTP (Fig- 
ure 6), Alice recomputes h from her knowledge of 
otp, and sends it to LastPass along with her LastPass 
username. LastPass checks its records for a matching 
username and h. It starts an authenticated session for 
(i.e., sets session cookies identifying) Alice and sends 
back her rand_encrypted_key. Alice then decrypts 
rand_encrypted_key to recover her master key. 

Vulnerability. We found that the request used to set 
up the OTP (Step 1 Figure 5) is vulnerable to a classic 
CSRF attack. The LastPass server authenticates Alice 
(in Step 1) only with her cookies. Since LastPass does 
not know the OTP or the master key, it cannot validate 
that rand_encrypted_key actually corresponds to an 
encrypted value of the master key. Fixing this vulnera- 
bility involves adding a CSRF token to the OTP creation 
form. 

OTP Attack on LastPass. An attacker, Mallory, who 
knows Alice's LastPass username, can come up with 
a string otp' and using the same algorithm as above, 
generate a forged value h' and rand_f ake_key with a 
made-up master key. On submitting the CSRF POST re- 
quest, LastPass will store h ' as authenticating Alice. 

Mallory can then use otp' to log-in to LastPass us- 
ing otp'. Of course, decrypting the rand_f ake_key 



will not give Mallory Alice's real master key. Nonethe- 
less, using this CSRF attack, Mallory obtains Alice's en- 
crypted password database. We find this leads to three 
attacks. 

First, LastPass stores the list of web application en- 
try points unencrypted, and Mallory can now read this 
list. This is a breach of privacy: starting with just Al- 
ice's LastPass username, Mallory now knows all the web 
applications Alice has accounts on. 

Secondly, the encrypted password database is now 
available to Mallory for offline guessing. Recall that the 
LastPass uses a key derived from Alice's master pass- 
word, which Alice has to memorize. Unlike the pass- 
words randomly generated by LastPass, this master pass- 
word is likely vulnerable to guessing. It is instructive to 
consider that, after a server breach, LastPass requires all 
its users to reset their passwords [41]. 

Finally, we also find that this attack leads to a denial 
of service attack. Mallory, logged in as Alice, can delete 
any credential in Alice's database, despite being unable 
to decrypt the database. Since the username is part of 
the credential, recovering all these credentials would be 
tedious, or in some cases impossible. 

4.3 Authorization Vulnerabilities 

Looking beyond vulnerabilities stemming from the na- 
ture of the web platform, we now discuss some vulnera- 
bilities that come from logic errors in the password man- 
ager. We found that two of the three password managers 
that support credential sharing both mistake authentica- 
tion for authorization. An attacker can create two fake 
accounts, Eve and Mallory, in the password manager and 
share Alice's credentials with Mallory by sending a cor- 
rectly crafted message from Eve's account. Importantly, 
the actual errors do not ever involve Alice or her browser 
and thus the attacks work in the absence of Alice visiting 
the attacker's website. 

4.3.1 Case Study: Myllogin Sharing Credentials 

Myllogin relies on client-side encryption of the creden- 
tial database. This complicates sharing: Alice and Bob 
need to share credentials, through Myllogin as an un- 
trusted channel. Myllogin relies on public -keys for both 
Alice and Bob to share credentials: when Alice shares 
a credential with Bob, Myllogin first encrypts it with 
Bob's public-key before sending it to Bob. This ensures 
that only Bob can see the shared credentials. 

Sharing Myllogin Credentials. Figure 7 illustrates 
how Alice shares a credential with Bob in Myllogin. 
In the first two steps, Alice obtains Bob's public key 
fcfo. Then, in Step 3, Alice (i.e., Alice's Myllogin in- 
stance) encrypts the credential with kb and sends the 
encrypted username alice.dropbox@gmail.com and 
password hunter 2 to Myllogin. 
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myiloginxom/index-in.php 

q Get_Public_Key \ email | wcid 



Myllogin 



POST my 1 Logm_REST_service.php 



wcid | send_to \ username \ 
| password\publickey 



POST my 1 Login REST service.php 



(~~) check cookies 
publickey | userid q 
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sendjo -Bob , check cookies 
wcid | shareld | email | userid 1L 



"id": 4097211, 
"memberjd": 3751238, 
"name": "Dropbox", 

"url": "https :// www.dropbox.com/login", 
" login " : " alice .dropbox@gmail.com", 
"note": {}, 

"created_at" : "2013-07-18T13:50:1 8-04:00", 
"updated_at": "201 3-07-1 8T1 3:50:1 8-04:00", 
"password-k": "AAQsrfjgfcWj/4FsP64BTYTJpbgpBK4+yltal", 
"settings": "{\"autologin\":\"1\", ...}", 
"member Jullname": "Alice Gordon", 



Listing 1 : Example PasswordBox asset 



Figure 7: Sharing Credentials on Myllogin 

Using the Shared Credential. Bob's Myllogin in- 
stance polls the Myllogin server for any updates. The 
Myllogin server notifies Bob of the newly shared cre- 
dential, sending him the information that Alice encrypted 
with his public key. Bob decrypts the shared credentials 
(username and password) for website url with his pri- 
vate key. Once Alice shares a credential with Bob, he can 
also update it. In such cases, Myllogin automatically up- 
dates the credential globally by sharing the update with 
collaborators on the web card (Alice, in this case). This 
occurs through essentially the same request as Step 3 in 
Figure 7, but this time Bob encrypts the credential with 
Alice's public-key. 

Vulnerability. Our analysis revealed that Myllogin 
only authenticates Alice before sharing a web card; it 
does not check whether Alice owns or has the authority 
to share the web card identified in the wcid (Step 3, Fig- 
ure 7). 

Myllogin Share Attack. Since Myllogin does not 
check wcid in Figure 7 Step 3, an attacker Mallory can 
share any web card (given its id) to a collaborator Eve. 
This vulnerability allows Mallory to steal any credential 
whose ID she knows (perhaps because Eve shared it in 
the past but revoked it later). 

Worse, further analysis revealed that web card ids are 
globally unique, auto-incrementing numbers. In Step 3, 
Figure 7, Mallory can even use numbers referring to 
cards not yet created. 

Suppose that wcid refers to a web card that belongs 
to (or will belong to) Alice. Mallory generates a dummy 
username and password like "userabc" and "pwdabcm," 
encrypts it and shares it with Eve. Eve receives the 
dummy credentials. While these credentials are useless, 
notice that this registered Eve as a collaborator on this 
web card, even if it belongs to Alice. 

In the future, whenever Alice or any other collaborator 
updates the web card, the Myllogin client automatically 
re-encrypts the real credential and sends it to each col- 



laborator, including Eve. It is trivial for Mallory to share 
all web cards, current and future, to Eve, who awaits up- 
dates to steal real credentials. 

In the attack above, Eve learns Alice's credentials only 
if Alice updates them after the attack. Alternatively, Eve 
can install new credentials to Alice's database without 
authorization from Alice. This allows Eve to execute a 
form of login CSRF attack [5]. Alternatively, Eve can in- 
stall wrong credentials to Alice's database, which would 
cause an error when Alice attempts to use them. It is 
likely that Alice, in response, would update the web card 
with her correct credentials and unknowingly share them 
with Eve. 

One concern is how to ethically verify the Myllogin 
authorization flaw without sharing another user's creden- 
tial by mistake. We observed over multiple days that it is 
rare that any other user creates a new web card between 
2am - 3am PST We then verified this vulnerability one 
day between 2am and 3am without sharing another user's 
credential by mistake. 

4.3.2 Case Study: PasswordBox Sharing Creden- 
tials 

PasswordBox stores a user's credential for a web appli- 
cation in a JSON-encoded asset file. Listing 1 presents 
an example asset for Dropbox. We focus on two 
salient properties: first, password_k is the encrypted 
value of Alice's password for dropbox. com and is the 
only encrypted field in the asset. Other details such 
as entry point URL, the name Alice used to register 
(member_f ullname) and so on, are all in cleartext. 

Second, our analysis revealed that asset_id is an 
auto-incrementing, unique (across all users) id for each 
asset. Assuming asset_id started at 1, we can infer that 
PasswordBox manages over 4 million assets, an assump- 
tion anyone can verify with the flaw we discuss next. (We 
did not, because of the obvious ethical concerns.) 

Sharing Credentials. Figure 8 shows how a user Al- 
ice shares one of her assets identified by asset_id to 
a collaborator Bob. On clicking share, the Password- 
Box extension on Alice's browser makes a POST re- 
quest to the passwordbox . com servers that includes the 
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passwordbox.com 

^shared | crypted_key | contact_id | asset_i 



POST /api/O/secrets 



PasswordBox 



check cookies 



Q asset_id \ contact_id \ created__at | ... q 

(a). Sharing an asset 



passwordbox.com 

o, 



PasswordBox 



GET /api/O/assets 



O 



[assets] 



i 



check cookies 



(b). Accessing a shared asset 



Figure 8: PasswordBox: Sharing an asset. The under- 
lined passwordbox.com on the left indicates that the 
code making the request runs in the passwordbox. com 
origin. 



contact_id, the contact to share credentials with (in 
this case, Bob's id); and asset_id, the id of the cre- 
dential to share (as in Listing 1). In the future, whenever 
Bob downloads the list of assets accessible to him, Pass- 
wordBox includes Alice's shared credential. 

Vulnerability. The absence of a CSRF token sug- 
gested the possibility of a CSRF flaw in the protocol. 
Fortunately (or, unfortunately), we found that Password- 
Box implemented a strong defense against CSRF at- 
tacks: it checks the Ref erer header as well as includes 
a special X-CSRF-Token in the headers of the HTTP 
request. Instead, we found a far more serious logic 
bug in the sharing assets functionality. In its sharing 
logic, PasswordBox never checks whether Alice owns 
the asset_id she is sharing. This allows Mallory to 
share assets she does not own with Eve, similar to the 
Myllogin attack (Section 4.3.1). 

PasswordBox Share Attack. Similar to the "share- 
and-update" attack on Myllogin, Mallory and Eve run 
through the protocol in Figure 8. Mallory can share 
any asset to Eve by simply setting asset_id. Since 
asset_id is an auto increment number, Mallory can it- 
erate through all possible asset_id and share all exist- 
ing 4 million assets with Eve. Listing 2 is the JavaScript 
snippet that Mallory used to share an arbitrary asset to 
Eve, whose contact_id is assumed to be 123. 

As we noted above, PasswordBox only encrypts the 
password field in an asset; disclosure of every user's full 
name, usernames, web application URLs, and creation 
times is a severe privacy breach. 



function share(asseUd){ 
var xmlhttp = new XMLHttpRequest(); 

var jsn = '{"shared":true, "cryptecLkey:" "ABC", "contactJd ": 123, 

"asseLid":' + asseUd + ' } ' ; 
xmlhttp. open("POST","https://api0.passwordbox.com/api/0/secrets",true); 
xmlhttp. setRequestHeader("Content-type", "application/json"); 
xmlhttp. send(jsn); 

2 

Listing 2: JavaScript snippet to share a asset with Eve 



4.4 User Interface Vulnerabilities 

Earlier, discussing bookmarklet vulnerabilities (Sec- 
tion 4. 1), we focused on the behavior of a password man- 
ager when the user is already authenticated to the pass- 
word manager. If the user is not authenticated to the pass- 
word manager, then the user needs to log in to her mas- 
ter account. This provides a potential avenue for phish- 
ing vulnerabilities and the password manager should not 
train bookmarklet users towards insecure practices. The 
ideal secure option in such a scenario is asking the user 
open a new tab (manually) and logging in to the pass- 
word manager. 

We find that only the Myllogin bookmarklet defaults 
to this secure behavior. Clicking on the Myllogin book- 
marklet, when not logged in, results in a message asking 
the user to open a new window and log in. We found that 
both RoboForm and LastPass bookmarklets were vulner- 
able to phishing attacks. Below, we discuss the Robo- 
Form vulnerability and present the LastPass vulnerabil- 
ity in our technical report [27]. We also have recorded 
video demonstrations of these attacks online [4]. 

Case Study: RoboForm. Recall that when Alice 
clicks her RoboForm bookmarklet, the bookmarklet cre- 
ates an iframe in the current web application. If Alice has 
not logged in to RoboForm, the iframe request redirects 
to the RoboForm login page, displaying a login form in 
the iframe. This design is insecure: it trains Alice to 
fill in her RoboForm password even when the URL bar 
(belonging to the surrounding web application) does not 
point to robof orm. com. An attacker can trivially block 
the RoboForm iframe load and spoof an authentication 
dialog that steals Alice's RoboForm credentials. A se- 
cure design would ask Alice to open a new tab to Robo- 
Form and log in. 

One concern with successfully carrying out this attack 
is detecting whether Alice is already logged in to Robo- 
Form. We found that the height of the RoboForm iframe 
(the dialog) is greater than 200px if and only if Alice is 
already logged-in. Using this side-channel, the attacker 
can modify the spoofed iframe to make the attack con- 
vincing. 
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5 Lessons and Mitigations 

We now attempt to distill the lessons learnt from our 
study and provide guidance to password managers on 
closing the vulnerabilities we found and mitigating fu- 
ture ones. Our focus here is on concrete guidance and 
defense-in-depth. We identify improvements in architec- 
tures and protocols to mitigate vulnerabilities as well as 
the use of browser mitigations like CSP. We also iden- 
tify anti-patterns that developers of password managers 
should avoid. Security reviewers and users can also rely 
on the patterns and (absence of) the mitigations we dis- 
cuss as indicators of the security of a password manager. 

5.1 Bookmarklet Vulnerabilities 

All the bookmarklets we studied were vulnerable. The 
root cause of these vulnerabilities is that the bookmarklet 
code executes in the untrusted context of the webpage. 
The web browser guarantees a secure, isolated execu- 
tion environment for iframes and we advocate an iframe- 
based architecture for securing password manager book- 
marklets. Modern features such as credential encryption, 
which requires secure client-side code execution, makes 
the use of defenses proposed in previous work impracti- 
cal [1]. 

Recommendation. We recommend password- 
managers rely on a design similar to proposed by Bhar- 
gavan et al. [8]. When the user clicks the bookmarklet, 
the bookmarklet code loads the password manager code 
in an iframe, running in the password manager's origin. 
The browser's same-origin policy isolates code executing 
in the iframe from the web application page and guaran- 
tees integrity of DOM APIs. 

The password manager's iframe uses postMessage 
for communicating with the application page and main- 
tains a simple invariant: a message carrying a creden- 
tial for dropbox.com has a target origin of https : // 
www . dropbox . com. The browser guarantees that only 
the Dropbox page receives the message. The only se- 
cret in the bookmarklet code is an HMAC function (pro- 
tected by DJS [8]) that the password manager iframe can 
use to provide click authentication (i.e., the user actually 
clicked the bookmarklet). Unfortunately, the presence of 
the secret in the bookmarklet allows linkability attacks. 

For unlinkability, we recommend password managers 
do not rely on such a secret and HMAC function. Dis- 
abling this secret loses the "click authentication" prop- 
erty. Since password manager browser extensions typi- 
cally include "auto fill" functionality, we believe the loss 
of click authentication is acceptable. If needed, the code 
in the password manager iframe could draw a dialog to 
ask for user confirmation before sharing credentials with 
the website. Such a design is vulnerable to clickjacking 
and we also recommend the use of upcoming mitigations 
for UI security [39]. 



Instead, password managers could rely on asking the 
user for permission to share credentials in the iframe cre- 
ated. 

The core issue behind bookmarklet vulnerabilities is 
the absence of secure (or "isolated") DOM APIs for 
bookmarklets. An alternative possibility is for browser 
vendors to provide bookmarklets with secure access 
to these DOM APIs, similar to the access granted to 
Chrome/Firefox extensions. 

5.2 Web Vulnerabilities 

We found a number of "classic" web application vulner- 
abilities in password managers. Based on the critical and 
sensitive nature of data handled by password managers, 
we recommend defense-in-depth features such as CSP 
and identify anti-patterns that developers should beware 
of. 

XSS. XSS is a well-studied problem and we will not 
recapitulate all the defenses for the same here. We rec- 
ommend that web applications, in addition to validating 
input and sanitizing outputs, should also turn on Con- 
tent Security Policy to provide a second layer of defense 
against XSS. The absence of a strong CSP policy in a 
password manager should raise red flags for users and 
reviewers. In the applications we studied, only Last- 
Pass shipped with a Content-Security-Policy header, al- 
beit with an unsafe policy that allows eval and inline 
scripts. 

CSRF. The prevalence of CSRF vulnerabilities in 
password managers surprised us. We recommend pass- 
word managers should include CSRF protection (via to- 
kens) for all their pages and forms. For defense in depth, 
these applications should also check the Referer and Ori- 
gin headers for all requests. While not a reliable de- 
fense, these headers provide a useful secondary layer of 
defense. 

One concern with CSRF tokens is the need to create 
and maintain state at the server-side. This could be cum- 
bersome for password managers that provide an interface 
through a browser extension: it is infeasible to request a 
new token before rendering every form. Instead, these 
applications can rely on special headers (e.g., X-CSRF- 
Token) for CSRF defense. The web security model dis- 
allows evil . com from setting headers for a cross-origin 
request. 2 

Secrets in JavaScript files. An anti-pattern we no- 
ticed was the presence of secret values — based off of 
tokens in the request URI or cookies in the request — 
in script files. Unfortunately, the web platform does 
not provide strong isolation guarantees for scripts: any 
(untrusted) origin can include scripts from the password 
manager's website. We recommend password managers 

2 Unless explicitly whitelisted by the receiving server via Access- 
Control-* headers. 
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serve all secret values in HTML or separate JSON files. 
This requirement is easy to check: the scripts used by the 
password managers should be the same across all users of 
the password manager. Serving user-specific JavaScript 
files based on tokens in the URI is a clear anti-pattern. 
An alternative is Defensive JavaScript [8], which pro- 
vides a principled defense to ensure secrecy of values in 
JavaScript code. 

5.3 Authorization Vulnerabilities 

The web application vulnerabilities discussed above 
stemmed from quirks of the web platform (e.g., ambi- 
ent authentication with cookies). Worryingly, we found 
a number of logic flaws in password managers classified 
under two broad categories. The first category, insuf- 
ficient authorization, creates vulnerabilities exacerbated 
by the second category, predictable identifiers. We iden- 
tify an anti-pattern, predictable identifiers, and the core 
security vulnerability, insufficient authorization, below 
and discuss mitigations. 

Insufficient Authorization. Confusing authentication 
with authorization is a classic security vulnerability. Out 
of the three password managers that support collabora- 
tion, we found insufficient authorization vulnerabilities 
in two of them. Unfortunately, these are logic flaws, 
and a simple mitigation is difficult. One possibility is 
for password managers to use a simpler sharing model. 
For example, let each credential have only one owner — 
only the credential's owner can change it or its collabo- 
rator list. A simple model eases authorization checks and 
could make insufficient authorization stand out. 

Predictable Identifier. Both our attacks on logic 
vulnerabilities rely on predictable identifiers (e.g., con- 
secutive integers). We recommend password managers 
switch to cryptographically secure random numbers for 
identifiers — this adds defense in depth, even if the server 
is careful to check authorization. The use of predictable 
identifiers should be rare and any use should be a cause 
for a security review. As we discussed earlier, the nature 
of the data handled by password managers warrants such 
a default-secure posture. 

5.4 User Interface Vulnerabilities 

Our proposed solution of relying on iframes and storing 
tokens in localStorage/cookies works seamlessly only if 
the user is already logged in. If this is not true, the iframe 
needs to ask the user to log in. As our attacks demon- 
strated, the only secure way to do this is asking the user 
to manually open a new tab and login. My 1 login is the 
only password manager relying on this design and we 
recommend other password managers adopt a similar de- 
sign. Cautious users can protect themselves against such 
an attack by always logging in using a new tab instead of 
trusting a popup or iframe. 



6 Related Work 

A number of researchers have investigated security of 
web-based password managers. Bhargavan et al. did a 
study on five password managers, along with a num- 
ber of other web services that provide encrypted stor- 
age of data in the cloud, and presented a number of 
web attacks that could violate the intended security of 
the products [7]. This work inspired a redesign of the 
LastPass bookmarklet to decrypt a user's credentials in- 
side LastPass's iframe, making it harder for an attacker 
to steal the master key. Adida et al. provide a compre- 
hensive overview of a number of attacks on password 
manager bookmarklets; we reuse some of the ideas but 
find that, with modern password managers relying on 
encrypted credentials, a new defense based on iframes 
is needed [1]. Belenko et al. studied the cryptographic 
properties of password managers for mobile devices and 
their vulnerability to brute force attacks [6]. 

In concurrent work, Blanchou and Youn [9] as well as 
Silver et al. [35] found a number of serious flaws in the 
auto-fill functionality in password managers. In contrast, 
we analyze a broader range of functionality but focus on 
third-party web-based password managers only. 

Bonneau et al. [10] presented a framework for eval- 
uating alternatives to passwords in terms of usability, 
deployability, and security. This framework highlights 
advantages of an idealized password manager, but our 
work demonstrates that, in practice, password managers 
have flaws in their implementations that critically under- 
mine their security. Similarly, recent work found imple- 
mentation flaws in other password alternatives such as 
SSOs [40, 38]. 

The common web attack vectors we considered, such 
as CSPvF and XSS, have seen a lot of work in the past 
decade. For attacks and defenses, we defer to prior litera- 
ture for comprehensive surveys on CSRF [43], XSS [18], 
and server-side defenses for both [26]. Recent work also 
focused on logic flaws and insufficient authorization in 
web applications [17, 37, 36]. 

The security of mutually distrusting JavaScript run- 
ning in the same origin (an important consideration in 
bookmarklet code) has not been a concern in the design 
of the web platform. Bhargavan et al. identified a number 
of flaws in bookmarklets and proposed a new subset of 
JavaScript called Defensive JavaScript to mitigate them, 
which we discussed in depth in Section 5.1. Defensive 
JavaScript [8] is the only work we are aware of that aims 
to protect a JavaScript gadget from the host webpage. A 
large body of work exists for the converse goal of pro- 
tecting a host webpage from third party JavaScript code 
(such as code that draws a gadget) [22, 3, 13, 28]; a sur- 
vey compares these approaches [15]. 
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7 Conclusions 

We presented a systematic security analysis of five web- 
based password managers. We found critical vulnerabil- 
ities in all the password managers and in four password 
managers, an attacker could steal arbitrary credentials 
from a user's account. Our work is a wake-up call for 
developers of web-based password managers. The wide 
spectrum of discovered vulnerabilities, however, makes 
a single solution unlikely. Instead, we believe devel- 
oping a secure web-based password manager entails a 
systematic, defense-in-depth approach. To help such an 
effort, we provided guidance and mitigations based on 
our analysis. Since our analysis was manual, it is pos- 
sible that other vulnerabilities lie undiscovered. Future 
work includes creating tools to automatically identify 
such vulnerabilities and developing a principled, secure- 
by-construction password manager. 
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